chore(container-runner): tighten comments - #5589

Stack for rivet-dev/actors

• #5585 feat(container-runner): self-sleep on repeated actor start
• #5586 feat(container-runner): sleep on startup idle timeout
• #5589 chore(container-runner): tighten comments 👈
• #5587 feat(container-runner): exit process when the last child sto …
• #5588 feat(container-runner): drain child before SIGTERM on engine …
• #5584 feat(container-runner): drain children and engine concurrent …
• #5565 fix(envoy-client): ack terminating stop commands so pegboard …
• main

Get stack: forklift get 5589
Push local edits: forklift submit
Merge when ready: forklift merge 5589

_{change zrxxyxls}

Review

This is a comment/doc-only `chore` — no logic changes. Verified against the diff and the underlying code:

• Confirms with the repo's em-dash convention: all 7 em-dash (—) occurrences removed are only on deleted lines; no em dashes remain in added text.
• Terminology cleanup ("Cloud Run" → "serverless"/"the serverless platform") is consistent and matches how the rest of the codebase already refers to Rivet's serverless model rather than the third-party GCP product.
• In monitor.rs, the module doc's detailed memory/CPU source preference lists were removed, but the detail didn't disappear — it now lives as per-variant doc comments on MemSource/CpuSource (declaration order still encodes preference order). Good move, not a loss.

One nit worth a look, low severity since it's comment-only:

• container-runner/src/main.rs, SIGTERM_BUDGET doc: the old text said "the engine drain and the child kills run concurrently, each bounded by this full budget," which precisely matches the code (tokio::join!(drain, stop_all_children(*SIGTERM_BUDGET)) — both get the full budget concurrently, not a split). The new text says they "share this budget concurrently," which reads more ambiguously and could be misread as the two operations dividing a single budget rather than each independently getting the full window. Might be worth restoring "each get the full budget" phrasing to avoid future confusion.

No functional, security, or test-coverage concerns — nothing here touches runtime behavior, so no new tests are expected.